Normalización:
Al diseñar bases de datos la normalización surge como una técnica para tener una medida de calidad sobre sus esquemas (aunque pueda variar según el contexto de uso). Se toma en un nivel conceptual (significado de las relaciones) y uno implementativo (cómo se almacenan físicamente las tuplas). Primordialmente, busca preservar la información y minimizar la información almacenada de forma redundante.

Pautas de diseño:
El proceso de normalización se basa en 4 pautas de diseño que pueden usarse como guía sin necesariamente determinarlo (no siempre son independientes entre sí).
Semántica: Diseñar los esquemas de manera que sea intuitivo entender el significado de sus atributos para evitar confusiones y malos usos. Esto implica no combinar atributos de diversos tipos de entidades y relaciones en la misma relación.
Almacenamiento: Minimizar el espacio ocupado por el diseño evitando anomalías de actualización. Entre ellas tenemos:
- Inserción: La incorporación de una nueva instancia de una entidad está ligada a la existencia de otra o puede producir inconsistencias con datos anteriormente cargados en la relación.
- Deleción: El borrado de una instancia produce que se pierda toda la información de otra.
- Modificación: Modificar una instancia de una entidad puede volver sus datos inconsistentes con los de las apariciones de una entidad en la relación.
Al permitir alguna de estas anomalías es preferente que estén debidamente indicadas para su correcta operación. Una razón por la que se suele violar esta pauta es la mejora en el rendimiento subyacente dada por el caso de uso (por la frecuencia de las consultas y actualizaciones puede convenir tener un campo de más pero de rápido acceso).
NULL: Evitar la presencia de valores nulos en las relaciones debido a su variedad de interpretaciones posibles (valor no aplicable, desconocido, concido y ausente). Cuando sean inevitables deben ser la excepción.
Tuplas espúreas: No crear descomposiciones en las que al reconstruir la información usando juntas esta no se corresponda con la original. Esto suele ocurrir cuando en una descomposición no se mantienen las claves de las entidades de la relación. Puede verificarse a través de consultas que usen ambas entidades.

Dependencias funcionales (DF):
Son herramientas formales utilizadas para analizar esquemas que ayuden a detectar algunos de los problemas mencionados. Representadas de la forma X -> Y donde X e Y son subconjuntos de atributos de la relación, nos dicen que los valores de Y dependen de los de X, imponiendo así una restricción sobre las posibles tuplas que se pueden formar.
Se especifican según la semántica de los atributos de la relación. Con ello, una instancia legal es aquella que las respeta (también llamada extensión o estado legal). Nótese que sólo con los datos no es posible determinarlas, aunque nos permiten confirmar su existencia o descartarlas.

Proceso de normalización:
Partiendo de las DFs y las claves de cada relación de una DB, podemos aplicarle una serie de tests para certificar si satisface una forma normal. De no hacerlo, se le puede aplicar un proceso de normalización enfocado en minimizar la redundancia y las anomalías de inserción, deleción y modificación para que en una nueva descomposición la DB pase estos tests. Nótese que las formas normales no garantizan un buen diseño de la DB.
Tras efectuar este proceso se buscan:
- Nonadditive Join (SPI): Garantía de que no se produzcan tuplas espúreas, es decir, se pueda recuperar la información original.
- Preservación de DF (SPDF): Cada DF esté representada en algún esquema resultante de la descomposición.
Lo primero se busca a cualquier costo, mientras que lo segundo es a veces sacrificado.
Una DF X -> Y es completa si al eliminar un atributo de X la dependencia deja de existir. Es parcial si sigue existiendo. Por otra parte, la cobertura minimal FM de un conjunto de dependencias F es tal que el lado derecho de cada dependencia tiene un sólo atributo y las dependencias son completas. Para formarla debemos descomponer los atributos a derecha, quitar los redundantes a izquierda y eliminar las DFs redundantes (no es conmutativo el proceso).

Formas normales basadas en Clave Primaria:
1FN: No deben haber relaciones dentro de relaciones o como atributos dentro de las tuplas. Esto implica que el dominio de los atributos sólo puede ser de valores atómicos (o sea, no pueden ser multivaluados). Para alcanzar esta forma normal suele tomarse el atributo en una nueva relación que tenga como PK a ambos atributos.
Otras opciones involucran expandir la PK (introduciendo posible redundancia) o dividir el atributo en la cantidad de valores que puede tomar (derivando en posibles valores nulos). A través de la aplicación recursiva de 1FN se pueden sacar las relaciones anidadas de una relación.
2FN: Todos los atributos no primos deben depender completamente de la PK de la relación. Para pasar a 2FN basta con descomponer en subesquemas en los que aparezcan los atributos de la PK de los que dependen como parte de su clave.
3FN: Una DF X -> Y es transitiva si tenemos un conjunto de atributos no primos Z tal que X -> Z y Z -> Y. Luego, en esta FN ningún atributo no primo debe depender transitivamente de la PK. Para satisfacerla garantizando SPI e SPDF tomamos la cobertura minimal Fm de la relación, formamos los subesquemas XA de cada DF X -> A, unimos los de igual lado izquierdo, agregamos uno con los atributos de una clave si ninguno de los resultantes contiene alguna y eliminamos los esquemas redundantes.
BCFN (Boyce-Codd Normal Form): Toda dependencia funcional no trivial X -> A de la relación debe tener a X como SK. Es más restrictiva que 3FN y al pasar a esta pueden perderse DFs ya que su proceso se basa en crear subesquemas reemplazando las DFs que violan esta FN.

Inferencia:
Una DF es inferida por un conjunto de DFs si se cumple para toda instancia legal de la relación que cumpla con este cojunto. Con esto, la clausura F+ de un conjunto de DFs F son todas las dependencias funcionales que pueden ser inferidas a partir de este. A partir de esta podemos hallar una CK X si X -> A pertenece y para ningún subconjunto Y de X, Y -> A peretenece (X entonces determina funcionalmente a todos los atributos de la relación).
Podemos calcular F+ aplicando las reglas de inferencia (o "axiomas de Armstrong"):
- RI1 (regla reflexiva): Si X contiene a Y entonces X -> Y.
- RI2 (regla de incremento): X -> Y implica XZ -> YZ.
- RI3 (regla transitiva): X -> Y e Y -> Z implican X -> Z.
Estas crean una clausura fiable (toda DF implicada a partir de F es inferida) y completa (F+ es determinada completamente a partir de F aplicando estos axiomas). Entre sus corolarios tenemos:
- RI4 (regla de descomposición o proyección): X -> YZ implica X -> Y.
- RI5 (regla de unión o aditiva): X -> Y e X -> Z implican X -> YZ.
- RI6 (regla pseudotransitiva): X -> Y e WY -> Z implican WX -> Z.